Assertion failure in get_attstatsslot() - Mailing list pgsql-hackers

From Bernd Helmle
Subject Assertion failure in get_attstatsslot()
Date
Msg-id E3625E1446621CD81C62AC9C@[172.26.14.62]
Whole thread Raw
Responses Re: Assertion failure in get_attstatsslot()
List pgsql-hackers
Consider the following small testcase:

BEGIN;

CREATE OR REPLACE FUNCTION upper(IN varchar, OUT varchar)
LANGUAGE SQL STRICT IMMUTABLE
AS
$$       SELECT pg_catalog.upper($1)::varchar;
$$;

CREATE TABLE foo(value varchar);

INSERT INTO foo SELECT 'helmle' FROM generate_series(1, 1000);

CREATE INDEX foo_upper_index ON foo(public.UPPER(value));

ANALYZE foo;

-- assertion failure
EXPLAIN SELECT 1 FROM foo WHERE UPPER(value) = 'xyz';

COMMIT;

While the sense of the UPPER() function is surely debatable (but it is used 
in this way in the database where the assertion failure was triggered), the 
EXPLAIN in the script crashes with

TRAP: FailedAssertion("!(((array)->elemtype) == elmtype)", File: 
"arrayfuncs.c", Line: 2970)
LOG:  server process (PID 15451) was terminated by signal 6: Abort trap

It took me a while to strip that down to this script, because it only 
happens when the statistics slots of the index are examined for the 
constant value in the where clause. The stavalues array holds type oid 
1043, whereas type oid 25 is expected.

I tried it back from current -HEAD to 8.3.11 and managed to reproduce it 
everywhere. Non-cassert builds are working correctly, so i'm not sure 
wether this is an over-aggressive assert() or masks a problem from 
somewhere else.

-- 
Thanks
Bernd


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: patch (for 9.1) string functions
Next
From: Robert Haas
Date:
Subject: Re: Bug? Concurrent COMMENT ON and DROP object